Subject: Re: SAS C 6.0 weirdness with __inline
From: [email-masked] (Doug Walker)
Date: 19 Oct 92 14:06:54 GMT
Newsgroups: comp.sys.amiga.programmer

In article <[email-masked]>, [email-masked] (Holger Kruse ) writes:
|> Yes, I had the same problem. When you use the global Optimizer and call
|> the __inline-function ONLY from the module where it has been defined,
|> everything works fine. But if you compile without global optimizer or
|> call the function from a different module, the linker will complain about
|> an undefined symbol.
|> At least this was my experience.
|> 
|> I reported that bug via EMITS about a week ago.

|> Holger Kruse
|> [email-masked]

This is not a bug.  The inlining is performed by the global optimizer.
Hence, if you don't run the global optimizer, you don't get inlining.
You will need to declare a "real" version of the function to compile
without the global optimizer in this case.

The global optimizer can't go around looking in all your .c files
for inline function definitions; it can only see the .c file you
are compiling and the .h files that it includes.  Hence, your
__inline function definition has to be in one of those files or it
won't be found.  The __inline substitution is done at compile-time,
NOT at link time.  It's exactly like #define macros; the preprocessor
only honors #define macros present in the .c file or a .h file
included by the .c file.  It doesn't even know about #defines in
some other .c file.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: [email-masked]                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.